1. Field of the Invention
Methods and apparatuses consistent with the present invention relate to communication using hypertext transfer protocol (HTTP), and more particularly, to implementing a real-time streaming using HTTP, and a client and a server used for the method.
2. Description of the Related Art
Streaming is transmission of video or audio from a server to a client through a network such as the Internet. The server breaks the video into packets so as to be transmitted through the network. The client collects the packets to recover the video and reproduces the video. Here, the reproduction and packet reception simultaneously occur. The packets associated here are referred to as streaming.
Streaming is distinguished from a simple file transmission for performing reproduction after receiving the entire video, in that the client reproduces video data while continuously receives the video data. The client simultaneously receives and reproduces streaming client packets and disuses the reproduced data. For streaming a file, protocols such as HTTP, file transfer protocol (FTP), real-time transport protocol (RTP), and real-time streaming protocol (RTSP) can be used. The HTTP and the FTP are inherently file transfer protocols, while the RTP and the RTSP are protocols for real-time file streaming.
FIG. 1 is a signal flow diagram for explaining real-time streaming using HTTP between a client and a server according to the related art.
Referring to FIG. 1, the client 100 and the server 110 cannot transceive information with each other while processing HTTP requests by using an existing HTTP protocol and cannot cope with a session state which continuously changes, so that the existing HTTP protocol is not suitable for real-time streaming.
A related art HTTP operates in that, as described above, an HTTP client always transmits a request, and an HTTP server transmits a response to the request. According to the aforementioned operation, when a state change in the HTTP server occurs, there is no method of notifying the change. In addition, there is no method of transmitting a request which is not a response from the HTTP server to the HTTP client. In addition, the HTTP client cannot receive a response to a new HTTP request from the HTTP server while processing a previous HTTP request. Lastly, when the HTTP response is divided into packets to be transmitted, there is no method of performing timestamping on each of the packets. Due to the restrictions, the HTTP has disadvantages for supporting real-time transport.
As a related art protocol supporting the real-time transport, there is the RTP. However, recently, for universal plug and play (UPnP) audio and video (AV)/digital living network alliance (DLNA), the HTTP is designated as a basic streaming protocol due to simplicity and convenience of the HTTP. In this case, it is necessary to enable real-time transport to be performed by only extending the HTTP. In addition, it is also important to enable the real-time transport to be performed by at least modifying an existing code.
A format of chunked encoding of HTTP 1.1 is shown by a Backus Naur Form (BNF) as follows.
Chunked-Body=*chunk last-chunk trailer CRLF
chunk=chunk-size [chunk-extension] CRLF chunk-data CRLF
chunk-size=1*HEX
last-chunk=1*(“0”) [chunk-extension] CRLF
chunk-extension=*(“;” chunk-ext-name [“=” chunk-ext-val])
chunk-ext-name=token
chunk-ext-vat=token|quoted-string
chunk-data=chunk-size(OCTET)
trailer=*(entity-header CRLF)
Where, * means that the following part is repeated by the number in front of the *, token means string represented by general American Standard Code for Information Interchange (ASCII) codes, and HEX means hexadecimal. A part included in ‘[‘,’]’ can be omitted, and contents of a part included in ‘(‘,’)’ are managed as one. CRLF represents ‘\r’ and ‘\n’.
The BNF is interpreted according to this rule in that, Chunked-Body represents that 0 or more chunk is repeated and when “last-chunk trailer CRLF” is shown, the Chunked-Body is completed. Here, the chunk includes “chunk-size chunk-extension CRLF chunk-data CRLF”, and “chunk-extension” can be omitted. Chunk-size means a magnitude represented as hexadecimal, “chunk-extension” has a repeated pair of a name and a value as shown as chunk-ext-name=chunk-ext-val”, and has a format having ‘;’ for division. Last-chunk includes one or more fields constructed with “0”, and chunk-extension and CRLF that can be omitted. Trailer includes 0 or more entity-header, for example a HTTP header. An example of the above chunk-body format is as follows.
1: 100; cen1=cev1; cen2=cev2; cen3\r\n
2: 100 bytes of chunk-data . . . \r\n
3: 200\r\n
4: 200 bytes of chunk-data . . . \r\n
5: 0\r\n
6: HTTP-Header: HTTP-Header-value\r\n
7: \r\n
In the chunk-body example, front numbers and ‘:’ represent line numbers. At the first line, “100” means that the size of following chunk-data is “100 bytes”, and “cen1= . . . cen3” is “chunk-extension”. Completion of chunk header information is represented as \r\n. In addition, at the second line, the chunk-data is transmitted, and at the end of the chunk-data, the \r\n is transmitted. At the third line, \r\n follows “200”. This exemplifies a case where “chunk-extension” is omitted. At the fourth line, similar to the line 2, real chunk-data is transmitted. At the fifth line which is the last chunk, after “0” is transmitted, \r\n is transmitted. After the last chunk, as shown at the sixth line, “trailer” including entity-header is transmitted. Lastly, as shown at the seventh line, \r\n is transmitted. An example of a complete HTTP response transmitting chunk-body as described above is as follows.
01: HTTP/1.1 200 OK\r\n
02: Transfer-Encoding: chunked\r\n
03: \r\n
04: 100; cen1=cev1; cen2=cev2; cen3\r\n
05: 100 bytes of chunk-data . . . \r\n
06: 200\r\n
07: 200 bytes of chunk-data . . . \r\n
08: 0\r\n
09: HTTP-Header: HTTP-Header-Value\r\n
10: \r\n
The second line shows that the HTTP server transmits data via chunked encoding through an HTTP header referred to as “Transfer-Encoding: chunked”.